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(54) System and method for stub retrieval and loading 


(57) A stub retrieval and loading subsystem is dis- 
closed for use in connection with a remote method in- 
vocation system. The stub retrieval and loading subsys- 
tem conirols the retrieval and loading ofa stub for a' re- 
mote method, into an execution environment, to facili- 
tate invocation of the remote method by a program ex- 
ecuting in the execution environment. The stub retrieval 
suosystem includes a stub retriever for initiating a re- 
trieval ci the stuo and stuD loader lor. when the stub is 


received by the stub retnever. loading the stub into the 
execution environment, thereby to make tne stub avail- 
able for use in remote invocation of the remote methco. 
In one embodiment, the stub retrieval and loacing sub- 
system effects the retrieval and loading (or a program 
operating in one address space provided oy one com- 
puter, of stub class instances to effect the remote invo- 
cation of methods wnich are provided by cojects ooer- 
ating in another address space, which may be oroviced 
by the same computer or a different computer 
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Description 

The invention relates generally to the field o( aigitat 
computer systems, ana more pantcuiarty to systems 
and methods for facilitating the invocation by a orogram 
ceing orocessed by a computer in one aadress soace. 
of orocessing of methods and procedures in another ad- 
cress scace. wnich may be fmpiemented either on the 
same ccmouter or on another computer. The invention 
canicutariy proviaes a system and method for obtaining 
ar.G dynamically loading "stub" information which facili- 
tates invocation by a program operating m one address 
space of a remote method or procedure m another ad- 
aress space and possibly on another computer 

in modern "enterprise" computing, a number of per- 
sonal computers, workstations, and other devices such 
as mass storage subsystems, network printers and in- 
terfaces to the public telephony system, are typically in- 
terconnected in one or more computer networks. The 
personal computers and workstations are used by indi- 
viGual users to perform processing in connection with 
data and programs that may be stored in the network 
mass storage subsystems, in such an arrangement, the 
personal ccmpuiers/wcrkstaiions. operating as clients, 
typically download the data and programs from the net- 
work mass storage subsystems for processing. In addi- 
tion, the personal computers or workstations will enable 
processed aata to be uploaded to the network mass 
storage subsystems for storage, to a networK printer for 
printing. to:he telephony interface for transmission over 
the public telephony system, or the like. In such an ar- 
rangement, the network mass storage subsystems, net- 
work printers and telephony interface operate as serv- 
ers, since they are available to service requests from all 
of the clients in the network. 3y organizing the network 
in such a manner the servers are readily available for 
■jse by ail of the oersonai computers/workstations in the 
"network. Such a network may be spread over a fairly 
wide area, with the personal computers/workstations 
being interconnected by communication links such as 
electrical wires or optic fibers. 

in addition to downloading information from servers 
for processing, a client, while processing a program, can 
remotely initiate processing by a server computer of par- 
ticular routines and procedures (generally "proce- 
dures"), in connection with certain "parameter" informa- 
tion provided by the client. After the server has proc- 
essed the procedure, it will provide results of its process- 
ing to the client, which the client may thereafter use in 
Its processing operations. Typically in such "remote pro- 
cedure calls* the program will make use of a local "stub" 
which, when called, transfers the request to the server 
which implements the particular procedure, receives the 
results and provides them to the program. Convention- 
ally, the stub must be compiled with the program, in 
which case the information needed to cat! the remote 
procedure must be determined at compile time, rather 
than at the time the program is run. Since the stub avail- 
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abie to tne client's orograms is static it m.ay oe at best 
the closest tnat can be determmec sncuid oe prov:cec 
for the orogram wnen it itne orccram; ;s ccmDnec. Ac- 
cordingly, errors and inefficiencies can oeveioo cue to 
s miismatches between tne stub that ;s orcviced to a oro- 
gram and tne reauiremenis of the remote procecure tnat 
IS called wnen the program is run 

The invention provices a new and tmoroved system 
and method for facilitating tne obtaining ana aynam.ic 

w loading of a stuD provided to enaoie a crogram CDerat;nc 
in one adares's: soace to remoteiv invoKe orocessina of 
a method or procedure m another address scace so 
that the stuo can be loaded by the program when tt is 
run and needed, rather than being statically cetermmec 

'5 when the program is compiled, indeed, the stub that is 
loaded can be obtained from the resource providing tne 
remote method or procedure, and so it uhe stub) can 
exactly define the invocation requirements oi the remote 
method or procedure. Since the stub can be located ana 

20 dynamically loaded while the program IS being run rath- 
er that being statically determined when the program is 
complied, run-time errors and inefficiencies which may 
result from mis-matches between the stuo that is pro- 
vided and the requirements of the remote method or pro- 

25 cedure that is invoked can be minimized. 

In bnef summary, the invention provides a stub re- 
trieval and loading subsystem for use in connection with 
a remote method invocation system The stuo retrieval 
and loading subsystem controls the retrieval and load- 

^0 ing of a stub for a remote method, into an execution en- 
vironment, to facilitate invocation of the remote method 
by a program executing in the execution environment 
The stub retrieval subsystem includes stub retriever for 
initiating a retrieval of the stub and stub loader for when 

'^s the stub IS received by the stub retriever loading the 
stub into the execution environment, thereby to make 
the stub available for use m rem.cie invocation of the 
remote method. In one embodiment, the stub retrieval 
and loading subsystem effects the retrieval and loading 

'^o for a program operating in one address space provided 
by one computer, of stub class instances to effect the 
remote invocation of methods which are provided by ob- 
jects operating in another address space, which may be 
provided by the same computer or a different computer. 

-^5 In that same embodiment, the stub retrieval and loading 
subsystem effects the retrieval and loading of a stub 
class instance when the remote object is referenced, al- 
though in other embodiments retrieval and loading may 
be effected when the remote method is invoked. 

^0 This invention is pointed out with particularity in the 
appended claims. The above and further advantages of 
this invention may be better understood by referring to 
the following description taken in conjunction with the 
accompanying drawings, in which: 

55 

FIG. 1 IS a function block diagram of a computer 
network including an arrangement constructed in 
accordance with the invention for facilitating the ob- 
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taintng, cynamic ioaaing and use of "stuD" informa- 
tion io enable a program operating tn one aacress 
space to invoke processing of a remoie methca or 
Droceaure in another address space. 
rlGs 2 and 3 are flow charrs oepiciing the opera- 
uons pertormed by the arrangement aepicieo m 
fiG 'i which IS useful in understanding the inven- 
tion with riG. 2 depicting operations performed in 
connection with obtaining and dynamic loading of 
the stuo information and FIG. 3 depicting operations 
cerrornned in connection with use of the stub infor- 
rr.aticn to invoke processing of the remote method 
or procedure. 

DETAILED DESCRIPTION OF AN ILLUSTRATIVE 
EMBODIMENT 

rIG. !s 3 schematic diagram of a computer network 
10 including an arrangement for facilitating dynamic 
loaaing of "stub" information to enable a program oper- 
ating in one address space to remotely invoke process- 
ing of a methoa or procedure in another address space. 
With reference to FIG. 1 . computer network 1 0 mciuaes 
a plurality of citent computers n( i) through 11 (Nl (.gen- 
erally identified by reference numeral lUn)). a plurality 
of server computers 12(1) through 12(M) (generally 
Identified by reference numeral l2(m)). ail of which are 
interconnected- oy a network represented by a commu- 
nication link 14. In addition, the network 10 may include 
at least one nameserver computer 13. which may also 
oe connected to communication link 14. whose purpose 
wtil oe described below. As is conventional, at least 
5cme of the client computers li(nj are m the form of 
oersonai computers or computer workstations, each of 
v;nicn iyptcally inctuoes a system unit, a video display 
'jnit ana operator input oevices such as a keyDoard and 
mouse (ait of wnicn are not separately shown). The sen/- 
er comoutars i2(m) and nameserver computer l3 also 
typically include a system unit (also not separately 
shown), ana may also include a video display unit and 
operator input devices. 

The client computers I1(n). server computers 12 
(m) and nameserver computer 1 3 are all of the conven- 
tional stored -program computer architecture. A system 
unit generally includes processing, memory, mass stor- 
age devices such as disk and/or tape storage elements 
and other elements (not separately shown), including 
network interface devices I5(n), 16(m) for interfacing 
the respective computer to the communication link 14. 
The video display unit permits the computer to display 
processed data and processing status to the operator 
and an operator input device enables the operator to in- 
put data and control processing by the computer The 
computers 1 1 (n) and 1 2(m) and 1 3 transfer information, 
in the form of messages, through their respective net- 
work interface devices I5(n), I6(m) among each other 
over the communication link 14. 

In one embodiment, the network 10 is organized in 


a 'client-server" configuration, m wnicn one or nnore 
computers, snown in FIG i as comcuters ',Zirrt) ooer- 
ate as servers, anc the other computers, snown m FiG 

I as computers 1 1 (n) ooerate as clients In one asoec: 
s one or more of the server computers 1 2(m) may as "fiie 

servers," include large-caoacity mass storage devices 
which can store copies of programs ana data which are 
available for retrieval by the client ccmouters over tne 
communication link 13 for use m their processing ooer- 

'0 ations From time to time, a client computer 11 (n) may 
also store data on the -server ccmouter 12. wmch may 
be later retrteveci by it (the client comouter that storec 
the data) or other client computers for use in their 
processing operations. In addition, one or more of the 
server computers 12(m) may. as 'compute servers." 
perform ceaain processing ooerations in response to a 
remote request therefor from a client computer n(n) 
and return the results of the processing to the requesting 
client computer n(n) for use by them (that is. the re- 

20 questing client computers ll(n)) m their subsequent 
processing, in either case, the server computers may 
be generally similar tothe client computers 11 (n). includ- 
ing a system unit, video aisoiay unit and operator input 
aevices and may be usable by an operator for data 

25 processing operations in a manner simitar to a client 
computer Alternatively, at least some of the server com- 
puters may include only processing, memory, mass 
storage and network interface elements for receiving 
and processing retneval. storage or remote processing 

30 requests from the client computers, and generating re- 
sponses thereto. It will be appreciated a client computer 

I I (n) may also perform operations described herein as 
being performed by a server computer i2!m.) and sim- 
ilarly a server computer l2{m) may also perform oper- 
as ations described herein as being performed by a client 

computer 1 1 (n). 

The network represented by communication link 1 4 
may comprise any of a number of types of networks over 
which client computers 11{n). server computers I2(m) 

-0 and nameserver computers 13 may communicate, in- 
cluding, for example, local area networks (LANs) and 
wide area networks (WANs) which are typically main- 
tained within individual enterprises, the public telephony 
system the Internet, and other networks, which may 
transfer digital data among the various computers. The 
network may be implemented using any of a number of 
communication media, including, for example, wires, 
optical fibers, radio links, and/or other media for carrying 
signals representing information among the various 

50 computers depicted in FIG. 1 . As noted above, each of 
the computers typically includes a network interface 
which connects the respective computer to the commu- 
nications link 14 and allows it to transmit and receive 
information thereover 

55 The invention provides a system for facilitating the 
obtaining and dynamic loading of 'stub" information to 
enable a program operating in one address space to in- 
voke processing of a remote method or procedure in an- 


3 


NSDOClD:<eP 080391 1A2> 


EP 0 803 811 A2 


oiner aadress space wnch may be located on the same 
computer as the invoking program or on a different com- 
puter The invention will be describea in connection with 
programs provided in the Java^** orogrammtng lan- 
guage, as aescribeo m the Java language specification, 
'.vntch are processed in connection with an execution 
environment which is provided by a Java vtrtual ma- 
chine The Java vmual machine, in turn, is specified in 
fhe Java vinual machine specification. As described m 
■he Java language specification, programs in the Java 
programming language define "classes" and "interfac- 
es." Classes are used to define one or more methods 
or procedures, each of which may be invoked by refer- 
ence to an interface. A class may be associated with 
and extend a "super-class." and in that regard will incor- 
porate all of the interfaces and methods of the super- 
class, and may also include additional interfaces and/or 
methods A class may also have one or more sub-class- 
es {and thus will comprise a super-class of each of its 
sub-classes), with each sub-class incorporating and 
possibly extending ihetr respective super-classes. 

An interface provides a mechanism by which a set 
of methods may be declared. In that connection, an in- 
(erface identifies each method that is declared by the 
interface oy. for example, a name, identifies the data 
type(s) of argument(s) that are to be provided for the 
method, the data type(s) of return values that are to be 
returned by the method, and identifiers for exceptions 
which can be thrown during processing of the method. 
A ciass may indicate that it implements a particular in- 
terface, and in that connection will include the program 
code whicn wilt be usea in processing all of the methods 
wnich are declared in the interface. In addition, different 
Classes may indicate that they implement the same in- 
terface and each will have program code which will be 
■jsea 'n processing all of the methods which are de- 
clared in fhe interface, but the program code provtaed 
.n each ciass to for use in processing the meihoas may 
differ from the program code provided in the other class- 
es which IS used in processing the same methods: thus, 
an interface provides a mechanism by which a set of 
methods can be declared without providing an indication 
of the procedure which will be used in processing any 
of the methods. An interface may be declared independ- 
ently of the particular ciass which implements the meth- 
od or methods which can be invoked using the interface, 
in that regard, a class that invokes the method and a 
class that actually implements the method will not need 
to share a common super-class. 

During processing of a Java program, as described 
in the Java virtual machine specification, a client com- 
puter n(n) provides an execution environment 20 for 
interpreting the Java program. The Java virtual machine 
includes a class loader 21 that, under control of a control 
module 19. can dynamically link instances of classes, 
generally identified in FIG. 1 by reference numeral 22. 
into the running program's execution environment while 
the program is being executed. In that operation, the 


control module i9 effectively enaoies :ne c;ass loace' 
to retrieve uninstantiatea classes wmcn generally laen- 
tified by reference numeral 23 mstanisaie ;hem anc un^ 
them as class instances 22 mio tne execution environ- 

j ment's address space at \ne Java orogram/s run time as 
the methocs which ine resoeciive ciasses 23 imoiement 
are called, in addition the ciass loacer 2i can oiscarc 
ones of the class instances 22 wnen tney are not neeaea 
or to conserve memory It will be appreciated that ff a 

'0 class instance 22 has been discardeo it may be relcac- 
ed by the class loader 2^ at a later ooint .f ;i is then need- 
ed. 

The invention provides an arrangement which facil- 
itates the remote invocation cy a orcgram executing in 
an execution environment 20 by a client computer n fn) 
of methods implemented by ciasses on a server com- 
Duter l2{m). In executing a metnco theservercomouter 
1 2fm) will also provide an execution environment 2-i for 
processing, under control of a coniroi module 25 the 

20 Java method. In that operation the Java virtual machine 
which provides the execution environment 2i induces 
a class loader 25 ( wnich may be similar to the ciass load- 
er 21 ) that, under control of the control mcauie 25 can 
dynamically link an instance of the class 26. to enable 

2S the method to be processed in the execution environ- 
ment 24. and instances of other classes taiso generally 
represented by reference numeral 26) which may be 
needed to process the remotely-invoked method. I n that 
operation, the control module 28 effectively enables the 

^0 class loader 25 to retrieve an unmstantiated class for 
the method to be invoked, from a plurality of unmstanti- 
ated classes which are generally identified by reference 
numeral 27 instantiate it (that is. the unmstantiated 
class which provides the method to be invoked) and link 

3S It as a class instance 26 into the execution environment 
In addition, the class loader 25 can discard the class 
instances 26 when processing of the method has termi- 
nated, it will be appreciated that, if class instances 26 
has been discarded, it may be reloaaed by the class 

•iO loader 25 at a later point if it is then neeaed. 

The structure of namesen/er computer 1 3. if provid- 
ed, is generally similar to that of the server computer 1 2 
(m). and will not be separately described. 

To facilitate remote invocation of a method, the con- 

J5 trol module 19 of the client computer's execution envi- 
ronment 21 makes use of one or more stub class in- 
stances generally identified by reference numeral 30 
which are provided as part of the execution environment 
2t in which the various class instances 22. including the 

50 class instance which is invoking the remote method, are 
betnq processed Each stub class instance 30 is an in- 
stance of nn unmstantiated stub class 31. which the 
server computer I2(m) may maintain for the various 
class instances 25 --ind uninstantiated classes 27 which 

55 the server computer 1 2(m) has "exported." that is. which 
the sen/er computer i2(m) makes available to client 
computers 1 1 (n ) lor use in remote invocation of methods 
provided thereby An uninstantiated sub class 3i in- 
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c:udes aectaraitons for the complete set of interfaces for 
[ne oanicuiar remote uninstantiateo class 27 wnich im- 
plements the remote method to be invoked, ana aiso 
provices or invokes methods which facilitate accessing 
or rne remote methodis) which are implemented by the 
remote class The unmsiantiatea stuo class 3i . when it 
15 .nstaniiaied and provided to the execution environ- 
ment 20 cf the Client computer n (n) as a stub class in- 
stance 30. eftectiveiy provides the information which is 
neeaed by the control module 1 9 of the execution envi- 
ronment 20 of the invoking Java program, so that, wnen 
a remote method that is implemented by its associated 
class is invoked by a Java program running in a partic- 
ular execution environment, the remote method will be 
processed and the return valuetsl provided to the invok- 
ing Java program. In one embodiment, the arrangement 
by which the stub class instance may be provided to the 
execution environment 20 is similar to that described in 
the Waldo, et al. , patent application entitled "System and 
Method for Generating Identifiers for Uniquely Identify- 
ing Object Types for Objects Used in Processing of Ob- 
ject-Oriented Programs and the tike", having the same 
crtoniy aate of the present aoplication. A copy of me 
Waiao ei al. patent application is filed herewith. 

In addition, the sen/er computer l2(m) provides a 
skeleton 32. which identifies the particular classes and 
methods which have been exponed by the server corn- 
outer i2(m) and information as to how it (that is. the 
sen/er computer 1 2(m)) may load the respective classes 
and inmate processing of the particular melhoas provid- 
ed thereby. 

When a class instance invokes a remote method 
maintained by a server computer 12(m). n will provice 
values for various parameters to the stub class instance 
30 for tne rem.ote method, which values the remote 
-netnod will use in its processing. If the remote method 
;5 imolemenied on the same computer as the invoking 
Java orogram. when the invoking Java program invokes 
a remote method, the computer may establish an exe- 
cution environment, similar to the execution environ- 
ment 20. enable the execution environment's class load- 
er to load and instantiate the class which implements 
the method as a class instance similar to class instances 
22 and process the remote method using values of pa- 
rameters which are provided by the invoking class in- 
stance in the remote invocation. After processing of the 
method has been completed, the execution environ- 
ment in which the remote method has been processed 
wilt provide the results to the stub class instance 30 for 
the remote method that was invoked, which, in turn, will 
provide to the particular class instance 22 which invoked 
the remote method. 

Similar operations will be performed if client com- 
puter 1 1 (n) and server computer 1 2(m) are implemented 
on different physical computers. In that case, in re- 
sponse to a remote invocation, the client computer 11 
(n) that is processing the invoking class instance 22. un- 
der control of the control module 19 for the execution 
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environment tO for tne invoking ciass instance 22 wiii 
use the aporopnate siuc ciass instance 30 to ccmm.uni- 
cate over :ne network representee by the communica- 
tion link U with the server comouier ' 2(m) wmcn imcie- 
5 menis :he remote method to enaole it ( tr.at is. tne server 
computer 1 2(m)) to estaonsn an execution environment 
24 for the ciass which implements tne remote metncc 
and to use the class loaoer 25 to loaa an instance c; me 
class as a ciass instance 25. in adouton. tne client com- 
•0 outer Tiin). aiso using the appropriate stuo ciass in- 
stance 30. will provtae any required parameter vaiues 
to the server computer I2(m) over the netwcrK 1- 
Thereafter, the sen/er computer i2(m) will process the 
remote method using parameter values so provtcec. to 
'5 generate result vaiue(S) which are transferred over tne 
network to the client computer n (n), in panicuiar :o the 
appropnate stub class instance 30. The client comouier 
n(n) will, after it receives the result valueisi :rom the 
network, provide them to the invoking class instance 22 
20 for its processing 

in any case, when the control module \ 9 of tne client 
computer's execution environment 20 ceiermines that 
a reference to the remote ooject has been receivec if it 
determines that the stub class instance 30 is not present 
wnen it receives the reference, it will attempt to obtain 
the stub class instance 30 from, for example, the server 
computer l2(m) which implements the remote methoc 
and enable the stub class instance 30 to be oynamically 
loaded in the execution environment 20 for the invoking 
^0 class instance 22. A reference to the remote cciect may 
■ be received, for example, either as a return value of an- 
other remote method invocation or as a parameter that 
!S received during another remote method invocation 
The stuD ciass instance may be dynamically loaded into 
i5 the execution environment in a manner simiiar to that 
used to load class instances 22 in the execution envi- 
ronment 22. The execution environment 20 is proviced 
with a stub class loader 33 which, under control of the 
control module 19. will attempt to find and load the stuo 
-0 class instances 30 as required by the class instances 
22 processed in the execution environment. The loca- 
tion of a particular server computer 1 2(m) that maintains 
the Class that implements a method to be invoked re- 
motely may be included in the call from the invoking 
-5 class instance or may be made known to the stub class 
loader 33 through another mechanism (not shown) 
maintained by the client computer 1 1 fn). 

However if the stub class loader 33 is not othenwise 
notified of which server computer 12(m) maintains the 
^0 class which implements a method which may be in- 
voked remotely ti may use the nameserver computer 
13 to provide tn>it identification. The identification may 
comprise riny locf oilier which may be used to identify a 
server computer i2!m) or other resource which is avatl- 
S5 able on me network 1 4 and to which the server computer 
1 2(m) can respond Illustrative identifiers include, for ex- 
ample, a network address which identifies the server 
computer and/or resource, or. if the network 1 4 is or in- 
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duces the internet, an identifier to. for example, a World 
Wiae Web resource which may provide the identification 
or a 'uniform resource locator' {"URL'l which orovides 
a uniform mechanism for identifying resources that are 
available over the Internet. The server computer 1 2fmi s 
wnich imolements the remote method, m resDonse to a 
recuesi from the client computer n (n) will provide stub 
class instance 30 which the client computer 11 (n) may 
load into the execution environment 21 to thereafter en- 
able me remote invocation to be initiated 

As noted above, if the stub class loader 33 does not 
know which server computer 12fm) implements the re- 
Tiote method which may be invoked (and thus does not 
know which computer is to provide the stub class code 
for the remote invocation), it may. under control of the 
control module 19. obtain the identification from the 
nameserver computer 13. in that operation, the stub 
class loader 33 may use a previously-provided default 
stub ciass which is provided for use in such cases The 
cefault class stub, when used by the invoking Java pro- 20 
gram, enables the computer that is processing the in- 
voking Java program to communicate with the name- 
server computer 13 to obtain information which can be 
used in invoking the remote method. This operation is 
essentially the same as the invocation of a remote meth- 
CO to be processed by the nameserver computer 13. 
wtih the remote method including a parameter identify- 
ing the class and method to be remotely invoked, and 
enabling the namesen/er computer 13 to provide the 
icentification of server computer 1 2fm) which can proc- ^0 
ess the method to the requesting client computer 1 1 in) 
and other information which may be helpful in commu- 
-^icating with the server computer I2(m) and invoking 
'ne oanicuiar method. It will be appreciated that the 
nameserver computer 1 3 will maintain a table (not sep- 
arateiy shown) of "exported" resources, that is. resourc- 
es, sucn 33 classes and methods, that are available to 
client computers llfn) connected to the network 14. and 
information, such as the identifications of the particular 
server computers 1 2(m) which provide those resources. -^0 
which will be useful to the client computers 1 1 (n) in mak- 
ing use of the exported resources. 

It wili be appreciated that the nameserver computer 
1 3 may create and maintain the exponed resource table 
in a number of ways that are known in the art. For ex- -^5 
ample, the nameserver computer 13 may periodically 
broadcast requests for exported resource information 
over the network 14 to which the various server com- 
puters l2(m) which maintain exported resources may 
respond: in that case, the nameserver computer 1 3 may so 
establish its exported resource table based on the re- 
sponses from the server computers 1 2(m). Alternatively, 
each of the various server computers 1 2(m) which main- 
tains an exported resource may periodically broadcast 
information as to the exported resources which it main- 55 
tains, and the nameserver computer 13 can update its 
exported resource table based on the broadcasts from 
the server computer. In addition, the nameserver com- 
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outer's exporteo resource table may oe estabusnec cy 
a system operator and may be fixed until ne or sne jd- 
oates It. 

In any case, the information orovioed by the name- 
sen/er computer 1 3 in response to a request mitiateo oy 
the default stub would include sucn information as for 
example, the loentification of a computer ]2im\ wnicn 
can provide a class which implements the remote me;n- 
od to be invoked, particular information wmch the com- 
puter {that IS, the computer which imDiemenis the re- 
mote method) will require to proviae the reauireo stuc 
class code, and the like. After receiving the information 
from the nameserver computer 13, the comouter u{n) 
that IS processing the invoking Java program may unaer 
control of the control module 19. use the information 
communicate with the computer (that is. the computer 
which implements the remote method) to obtain tne stuD 
class, and may thereafter invoke the method as ce- 
scribed above. 

With this background, the operations performed by 
client computer i1(n). server computer i2{m) and, ;f 
necessary, nameserver 13 in connection with obtaining 
and dynamic loading of stub ciass instance when a ref- 
erence to a remote method is received will be descnoed 
in connection with the flow chart depicted m FIG. 2, In 
addition, operations performed by the client computer 
1 1 in) and server computer in connection with remote in- 
vocation of a method using the stub class instance will 
be described in connection with the flow ctian depicted 
in FIG. 3. With reference initially to FIG. 2, the execution 
environment control module 1 9 will when it receives a 
reference to a remote method, will initiaiiy oetermine 
whether an appropriate stub class instance is present 
in the execution environment 20 to facilitate invocation 
of the remote method (step 100) If the control mooule 
1 9 determines that such a stub class instance 30 for the 
remote method is present in the execution environment. 
It may continue other operations (step 101 ), However, if 
the control module 19 determines in step i0i that such 
a stub class instance is not present in the execution en- 
vironment 20 for the remote method, the control module 
1 9 will use the stub class loader 33 to attempt to locate 
and load a stub class instance 30 for the class to process 
the remote method. In that case, the control module 19 
will initially determine whether the invocation from the 
class instance 22 included a resource locator to identify 
the server computer I2(m) or other resource which 
maintains the class for the method to be invoked, or 
whether it (that is. the control module 19) or the stub 
ciass loader 33 othen^^ise are provided with such a re- 
source locator (step 102). If the control module 19 
makes a positive determination in that step, it will se- 
quence to step 103 to enable the stub class loader 33 
to initiate communications with identified server compu- 
ter I2(m) to obtain stub class instance for the class and 
method to be invoked (step 103). When the stub class 
loader 33 receives the stub class instance 30 from the 
server computer I2(m), it will load the stub class m- 
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stance 30 into sxecuiion environment 20 for the ciass 
instance 2i wnicn initiated the remote method invoca- 
tion call in step lOO (step 104). Alter the stub class in- 
stance 30 for the referencea remote methoa has been 
icaced tn the execution environment, the method can 
CQ invoKeo as will be described below in connection with 
r'-G. 3 

Returning to step 102. if the control module 19 de- 
termines that the invocation from the class instance 22 
Old not :nciuce a resource locator to identify the server 
ccmouter 2(mo or other resource which maintains the 
Class for :ne methoa to be invoke, and f unher that it (thai 
IS. :ne control module 1 9) or the stub class loader 33 is 
net otherwise provided with such a resource locator, a 
"ciass not found" exception may be indicated, at which 
point :ne control module 19 may call an exception han- 
aier The exception handler may perform any of a 
numcer of recovery operations, including, for example, 
merely notifying the control module 19 that the remote 
method could not be located and allow it to determine 
subsequent operations. 

.Alternatively, the control module 19 may attempt to 
obtain a resource locator from the namesen/er compu- 
ter 13 or other resource provided by the network 14 
(generally represented in FtG. 1 by the nameserver 
computer 1 3). using a call to. for example, a default stub 
ciass instance 30 The call to the default stub class in- 
stance 30 wiil include an identification of the class and 
methoa to be invoked and the name ofthe nameserver 
com.outer i3(m). Using the default stub class instance 
30 the control module 19 will enable the computer 11 
(n) to initiate communications with namesen/er compu- 
ter ! 3 ;o cctain an identifier for a server computer 1 2(m) 
wntcn maintains the ciass and method to be invoked 
istep ' iO) The com,munications from the default stub 
Class instance 30 will essentially correspond to a remote 
metncG invocation, with the method enabling the name- 
server comouter to provide the identification for the serv- 
er com.puter i2(m). if one exists associated with the 
class and method to be remotely invoked, or alternative- 
ly to provide an indication that no sen/er computer 12 
(m) iS identified as being associated with the class and 
methoa During the communications in step 110. the de- 
fault stub class interface 30 will provide, as a parameter 
value, the identification of class and method to be in- 
voked. 

in response to the communications from the default 
stub class instance 30. the nameserver computer 1 3 will 
process the request as a remote method (step ill), with 
the result information comprising the identification for 
the sen/er computer t2{m), if one exists that is associ- 
ated with the class and method to be remotely invoked, 
or alternatively an indication that no server computer 1 2 
(m) is identified as being associated with the class and 
method. After finishing the method, the nameserver 
computer 1 3 will initiate communications with the default 
stub class instance 30 to provide the result information 
to the default stub class instance 30 (step 112). 


After receipt of tne result inicr-r.aticn :rcm :ne 
nameserver computer 13 the derauit stuo c;as3 in- 
stance, under control of the control moGuie 1 9 wiil oass 
result information to the stub class loacer 33 - step n 3> 

5 Thereafter, the stub class :caaer 33 determines wnether 
the result information from the nameserver ccmputer 
comprises the identification for the server comouter 12 
(m) or an indication that no .sen/er :omcuier l2!mf is 
identified as being associatec with tne ciass 'Steo 1 1 ^) 

'0 If the Stub class loader 33 determines that tne result in- 
formation comprises the tceniificaiicn for tne serve^ 
computer i2(m). it {that is the stuo ciass loaaer 33) wiii 
return to step 101 to initiate communjcaiion witn the 
identified server computer 1 2[m) to cciam stuo class m- 

^5 stance for the class and method tnat may be mvckeo 
On the other hand, if the stuo class loader 33 determines 
in step 114 that the nameserver comouter 13 had pro- 
vided an indication that no server comouter !2{mi is 
identified as being associated with the class and method 

20 that may be invoked, the "ciass not found' exceotion 
may be indicated (step 115) and an exception .nanoier 
called as described above 

As noted aoove. the stub ciass -nstance 30 re- 
trieved and loaded as described aoove m connection 

25 with FIG. 2 may be used m remote invocation of the 
method. Operations performed by the client computer 
n(n) in connection with remote invocation of the meth- 
od will be described in connection with the flow chart ;n 
FIG. 3. As depicted in FIG. 3. when a ciass instance 22 

30 invokes a method, the control module 19 may initially 
verify that a stub class instance 30 is present m the ex- 
ecution environment for remote methoa to be invoked 
{step 120). If a positive determination is made in step 
(20. the stub class instance 30 will be used for the re- 

35 mote invocation, and in the remote invocation will pro- 
vide parameter values which are to be used in process- 
ing the remote method (step 121 ). Thereafter the stuo 
ciass instance 30 for the remote metnod that may oe 
invoked will be used to initiate communications with the 

■io server computer 1 2(m) which maintains the class for the 
remote method (step 122). in the process, the passing 
parameter values which are to be used in processing 
the remote method wilt be passed. It will be appreciated 
that, if the sen/er computer I2(m) which is to process 

-'5 the method ts the same physical computer as the client 
computer l2fn) which is invoking the method, the com- 
munications can be among execution environments 
which are being processed within the physical compu- 
ter. On the other hand, if the sen/er computer l2(m) 

50 which IS to process the method is a different physical 
computer from that of the client computer I2(n) which 
IS invoking the method, the communications will be 
through the client computer's and server computer's re- 
spective network interfaces I5(n) and 16(m) and over 

55 the network 1 4. 

In response to the communications from the stub 
class instance in step 122. the sen/er computer 12(m). 
if necessary establishes an execution environment 24 
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for the class wntch maintains the method that may oe 
invoKea. and the uses the information provided Dy ihe 
sKeieton 32 to create a class instance 26 for that class 
isteo 123). Thereafter, the sen/er computer 12(m). un- 
aer control of the control module 2S. wtil process the 
methoa m connection with parameter values that were 
::roviced dy stuD class instance 30 (step )24i. After 
comcietina processing of the method, the server com- 
outer i2(m). aiso unaer control of the control module 2S. 
v/ni initiate communications with the client computer's 
5tuo class instance 30 to provice result information to 
■he stub class instance istep 125). in a manner similar 
to that described above in connection with step 102. if 
the sen/er computer 1 2(m) which processed the method 
is the same pnysicat computer as me client computer 
i2(ni which invoked the method, the communications 
can oe among execution environments 24 and 20 which 
are being processed within the physical computer On 
the other hana, if the server computer i2(m) which proc- 
essed the method is a different physical computer from 
that of the client computer i2(n) which is invoking the 
method, the communications will be through the server 
computer's and client 7 computer's respective network 
interfaces l5(m)and l5(n) and over the network 14. Af- 
ter the stub 5 class instance 30 receives the result tn- 
iormation from the server computer, it may provide re- 
sult information to the class instance 22 which initiated 
the remote method invocation {step 1 26). and that class 
instance 22 can continue processing under control of 
the control module 1 9 

Returning to step 120. if the control m.odule 19 de- 
termines in that step that it does not have a stub class 
-nstance 30 that is appropriate for the remote method 
tnat may oe invoked, it may at that point call an excep- 
tion nandler (step 1 27) to perform selected error recov- 
sry operations. 

The invention orovides a number of advantages In 
particular, it provices a new system ana method for fa- 
cilitating dynamic loading of a stuD which enables a pro- 
gram that is operating in one execution environment to 
remotely invoke processing of a method in another ex- 
ecution environment, so that the stub can be loaded by 
tne program when it is run and needed. In systems m 
wnich stubs are compiled with the program, and thus 
are statically determined when the program is compiled, 
they (the stubs) may implement subsets of the actual 
set of remote interfaces which are supported by the re- 
mote references that is received by the program, which 
can lead to errors and inefficiencies due to mismatches 
between the stub that is provided to a program and the 
requirements of the remote procedure that is called 
when the program is run. However, since, in the dynamic 
stub loading system and method, the stub that is loaded 
can be obtained from the particular resource which pro- 
vides the remote method, it (the stub) can define the ex- 
act set of interfaces to be provided to the invoking pro- 
gram at run time, thereby obviating run-time incompat- 
ibilities which may result from mis-matches between the 


stub tnat is provided anc the reauirements *ne remote 
method that is invoked 

It will be aporeciated that a numcer of modifications 
may be made to the arrangement as oescncec aoove 

r for examcle altnough the execution environment 2C 
has been aescnbed as ootaining anc loacmc stuc c:ass 
instances to facilitate invocation ci remote memoes 
wnen references to the remote methccs are receivec t 
wilt be appreciated that stub ciass instances may m- 

• 0 stead be obtained ana loacea when tne remote mstnccs 
are initially invoked. Obtaining ana loacirg of tne stub 
class instance for a remote methoc wnen a reference 
thereto ts received will have the advantages that iii the 
stub class instance will be present ;n the execution en- 

'5 vironment when the remote methoc is actually ;nvoKec 
and (ii) if the aoproonate stub class instance can not ce 
located, the program or an operator may be nctifiec at 
an early time. On the other hand, obtaining and ioacmg 
of the stub class instance for a remote .method wnen the 

20 method is to be invoked may result in a delay of the in- 
vocation until the correct stub ciass instance can be 
founc, if the method is in fact not invoked even if a ref- 
erence to it IS received the stub class instance may not 
need to oe located and loaded. 

■?5 It will be appreciated that a system m accordance 
with the invention can be constructed m wnoie or in cart 
from special purpose hardware or a general purpose 
computer system, or any combination thereof any por- 
tion of which may be controlled by a suitable program 

30 Any program may in whole or in part comprise pan of or 
be stored on the system m a conventional manner or it 
may in whole or in part be proviaec m to the system over 
a network or other mechanism for transferring informa- 
tion in a conventional manner In acciiion. :£ will oe ap- 

3S preciatec that the system may be ocerated anc/or oth- 
erwise controlled by means of information provided by 
an operator using ooerator input elements (not shown j 
whicn may be connected directly to the system or which 
may transfer the information to the system over a net- 
work or other mechanism for transferring information in 
a conventional manner 

The foregoing description has been limited to a spe- 
cific embodiment of this invention It will be apparent, 
however that various variations and modifications may 

-'5 be made to the invention, with the attainment of some 
or all of the advantages of the invention. It is the object 
of the appended claims to cover these and such other 
variations and modifications as come wtthin the true 
spirit and scope of the invention. 

so The processes described above may be perlormed 
by a computer program running on a computer in the 
embodiment described. Such a computer program can 
be recorded on a recording medium (for example a mag- 
netic disc or tape, an optical disc or an electronic mem- 

55 ory device, such as a ROM) in a way welt known to those 
skilled in the art, When the recording medium is read by 
a suitable reading device, such as a magnetic or optical 
disc drive, a signal is produced which causes a compu- 
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*er lo oerform the processes aescribea 

The processes may also be performed by eiectror^ic 
means. 

Claims 

1. For use in connection with a remote method invo- 
ca-.icn system, a stub retrieval and loading subsys- 
■ err. for controlling the retrieval and loading of a stub 
for a remote method into an execution environment 
[o laciiiiate invocation of the remote method by a 
program executing in said execution environment. 
!he stub retrieval subsystem comprising; 

A. a stub retriever for initiating a retrieval of said 
stub: and 

3 a stub loader for. when said stub is received 
by said stub retriever, loading said stub tnto 
said execution environment, thereby to make 
the stub available for use in remote invocation 
of said remote method. 

2. A stuD retrieval and loading subsystem as defined 
in Claim i fu'^ther including a remote method refer- 
ence detector for detecting whether a remote meth- 
co reference has been received in said execution 
environment, the stub reinever initiating retrieval of 
said stub when the remote method reference detec- 
tor detects that a remote method reference has 
been received in said execution environment. 

3. A stub retrieval .and loading subsystem as defined 
m Claim 1 further including a remote method invo- 
cation control for controlling invocation of said re- 
mote method, said stub retriever initiating retrieval 
ci saic stub when the remote method is invoked 

4. For use in connection with a remote method invo- 
cation method, a stub retrieval and loading method 
for facilitating the retrieval and loading of a stub for 
a remote method into an execution environment to 
faciiitate invocation of the remote method by a pro- 
gram executing in said execution environment, the 
stub retrieval method comprising the steps of: 

A. a stub retrieval step for initiating a retrieval 
of said stub; and 

B. a stub loading step for. when said stub is re- 
ceived, loading said stub into said execution 
environment, thereby to make the stub availa- 
ble for use in remote invocation of said remote 
method. 

5. For use in connection with a remote method invo- 
cation method, a signal for controlling the retrieval 
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and icaaing of a stuo for a rem.oie meincc 'nio ar 
execution environment lo facilitate mvccaticn c: :re 
remote metnca by a program executing m saic ex- 
ecution environment the signal causmo the com- 
puter to perform 

A. a stub retrieval step for initiating a retrieval 
of said stub; and 

B a stub loading step for. wnerTsaic stub is re- 
ceived, loading said stuD into saio execjvcn 
environment, thereoy to make the stuo availa- 
ble for use in remote invocation cf saic re.mcte 
method. 

15 

S. A method of storing data on a recording meaium 
the method comprising stonng data representative 
of a signal, which signal is for use tn connection wuh 
a remote method invocation method, the signal be- 
20 ing for controlling the retrieval and loading of a stuc 
for a remote method into an execution environment 
to facilitate invocation of the remote method by a 
program executing m said execution environment, 
the signal causing the computer to perform: 

25 

A. a stub retrieval step for initiating a retrieval 
of said stub: and 

B. a stub loading step for. when said stub fs re- 
^0 ceived. loading said stub into said execution 

environment, thereby to make the stub availa- 
ble for use in remote invocation of said remote 
method. 

j5 7. A method as defined m claim 4 or 6. or a signal as 
defined in claim 5 further including a remote meihcc 
reference detection step for detecting whether a re- 
mote method reference has been received in said 
execution environment, the stub retrieval step m- 
-^0 eluding the step of initiating retrieval of said stub 
when a remote method reference has been re- 
ceived in said execution environment. 

8. A method as defined in claim 4 or 6. or a signal as 
defined in claim 5 further including a remote method 
invocation control step for controlling invocation of 
said remote method, said stub retrieval step includ- 
ing the step of initiating retrieval of said stub when 
the remote method is invoked. 

so 

9, For use in connection with a remote method invo- 
cation system, a stub retrieval and loading compu- 
ter program product for controlling a computer to. tn 
turn, control the retrieval and loading of a stub for a 

55 remote method into an execution environment to fa- 
cilitate invocation of the remote method by a pro- 
gram executing in said execution environment, the 
stub retrieval computer program product compns- 
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ing a compuier-reaaabie medium having encoaed 
mefeon 

A. stub retriever code devices to enable saia 
computer to initiate a retrieval of said stub and 

3 a stuD loader code devices to enable said 
ccnnputer to. wnen said stub is received, load- 
ing said stub into said execution environment, 
tnereoy to make the stub available for use in 
remote invocation of said remote method. 

10. A stub retrieval and loading computer program 
proauct as defined m claim 9 further including re- 
mote method reference detector code devices for 
enabling said computer to detect whether a remote 
method reference has been received in said execu- 
tion environment, the stub retriever code devices 
enabling said computer to initiate retrieval of said 
stud when the remote method reference detector 
code aevices enable said computer to detect that a 
remote method reference has been received in said 
execution environment. 

11. A stub retrieval and loading computer program 
orcduct as defined in claim 9 further including re- 
mote method invocation control code devices for 
enabling said computer to control invocation of said 
remote method, said stub retriever code devices 
enabling said computer to initiate retrieval of said 
stub when the remote method is invoked. 

1 2. A suDsystem as aefined m any one of claims l to 3. 
a method as defined in any one of claims 4. or 5 to 
S. computer program product as defined in any one 
of claims 9 to 11 . or a signal as defined in any one 
of ciaims 5 or 5 to e the remote method invocation 
system further including a server for processing 
said remote method in response to a processing re- 
quest therefor, the server further providing said stub 
in response to a retrieval request from said stub re- 
triever 

13. A subsystem, method, computer program product 
or signal as defined in claim 12 in which server pro- 
vides a separate address space for processing said 
remote method from an address space provided by 
said execution environment. 

14. A subsystem, method, computer program product, 
or signal as defined in claim 1 3 in which the address 
space provided by said server and the address 
space provided by said execution environment are 
provided by separate computers. 

15. A stub retrieval and loading subsystem as defined 
in claim 12. 13 or 14, further comprising a remote 
server identifier for providing a server identification 


for laentifying said server 

16. A stub retrieval and loaaing sucsystem as certnec 
in ciaim 15 further including a remote meinoc refer- 

s ence detector for aetecnng whether a remcte meth- 
od reference has been received m saic execution 
environment, the remcte method reference =nc;ua- 
ing a remote method server lOentifier the remote 
sen/er identifier using the remote method server 

10 identifier as the server identification* 

17. A stub retrieval and loading subsystem as oefmec 
in claim 15 further inciuoing a remote methoo invo- 
cation control for providing a remote methoo mvc- 

/5 cation identification for controlling invocation of saio 
remote method, the remote method invocation pro- 
viding a remote method server toenttfier the rem.cte 
server identifier using the remote method server 
identifier as the server identification 

20 

18. A method or signal as defined m claim 12, 1 3 or 14- 
fuaher comprising a remote server identification 
step for providing a sen/er identification for identify- 
ing said server 

25 

19. A method or signal as defined in claim 13 funher 
including a remote method reference detection step 
for detecting whether a remote method reference 
has been received in said execution environment 

30 the remote method reference including a remote 
method server identifier the remote method server 
identifier being used during the remote method ref- 
erence detection step as the sen/er identification 

35 20. A method or signal as defined in claim 15 further 
including a remote method invocation control step 
for providing a remote method invocation loentifica- 
tion for controlling invocation of saio remote meth- 
od, the remote method invocation providing a re- 

40 mote method sen/er identifier the remote method 
server identifier being used during the remote meth- 
od reference detection step as the server identifica- 
tion. 

-iS 21. A subsystem as defined in claim 15. 16 or 1 9. or a 
method or signal as defined in claims 19. 1 9 or 20 
the remote method invocation system further in- 
cluding a nameserver for providing a said server 
identification, said remote server identifier initiating 

50 communication with said nameserver to obtain the 
sen/er identification for said remote method 

22. A stub retrieval and loading computer program 
product as defined in claim 12. 13 or 14. further 
55 comprising remote sen/er identifier code devices for 
enabling said computer to provide a sen/er identifi- 
cation for identifying said server 
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23. A sluD retrieval and loaamg compuier srcgram 
Droauct as defined m claim 22 further including re- 
mote method reference aetecior coae devices for 
enabling said compuier to detect whether a remote 
method reference has been received m saia execu- 
tion environment, the remote method reference m- 
clucing a remote method server identifier, the re- 
mole server identifier code devices enabling said 
computer to use the remote method server identifier 
as the server identification 

24. A stub retrieval and loading compuier program 
product as defined in claim 22 further including re- 
mote method invocation control code devices for 
enabling said computer to provide a remote method 
invocation identification for controlling invocation of 
said remote method, the remote method invocation 
providing a remote method server identifier, the re- 
mote server identifier code devices enabling said 
computer to use the remote method server identifier 
as the server identification. 

25. A stub retrieval and loading computer program 
product as defined in claim 22 the remote method 
invocation system further including a nameserver 
for oroviding a said server identification, said re- 
mote server identifier code devices enabling said 
computer to initiate communication with said name- 
sen/er to obtain the server identification for said re- 
mote method. 

26. For use in connection with a remote method invo- 
cation system, a stub retrieval and loading suDsys- 
tem for controliing the retrieval and loading of stub 
for a remote method into an execution environment 
10 facilitate invocation of the remote methoa by a 
crogram. executing in said execution environment, 
ihe stub retrieval subsystem comprising: 

A. a computer: and 

8. a control arrangement for controlling said 
computer, said control arrangement compris- 
ing: 

I a stub retrieval module for controlling said 
computer to initiate a retrieval of said stub: 
and 

ii. a stub loader module for controlling said 
computer to. when said stub is received in 
response to said stub retrieval module, 
load said stub into said execution environ- 
ment, thereby to make the stub available 
for use in remote invocation of said remote 
method. 

27. A control arrangement for use in connection with a 


comouter to control tne retrieval ano .cacir.g cr a 
stuc for a remote metnoc inio an execution environ- 
ment to facilitate invocation of ine remote metnoc 
by a orogram executing in saic execunon envircn- 
5 ment said control arrangement comcnsing 

1 a stub retnevai mocuie for controlling sa-c 
computer to initiate a retrieval of said stuc anc 

w ti a stub loader module for ccnrrolling saiG com- 

puter to..when"said siuo is receivec in resccnse 
10 said sruD retrieval module, loac saic stub '.ntc 
said execution environment tnereoy to make 
the stub available for use in remote invocation 

IS of said remote method. 

28. A system for aistributing code stored on a compuier 
readable medium and executable oy a computer 
the code including a plurality of moduies each ccn- 

20 figured to control the computer ;o facilitate the re- 
trieval and loading of a stub for a remote method 
into an execution environment to facilitate invoca- 
tion of the remote method by a orogram executing 
in said execution environment, said system com- 

25 prising: 

I. a stub retrieval module for controlling said 
computer to inittate a retrieval of said stub: and 

30 II a stub loader module for controlling said com- 

puter to. when said stub is received m response 
to said stub retrieval module, load said stuo into 
said execution environment. ihereDy to make 
the stub available for use m remote invocation 

35 of saic remote method 

29. A signal according to any one of claims 5 1 2 to 1 4 
or 18 to 21. wherein tne signal is recordec on a re- 
cording medium 

JO 

30. A signal according to claim 29. wherein the record- 
ing medium comprises a magnetic disc, a magnetic 
tape, an ootical disc or an electronic m.emory ae- 
vice. 

45 
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NO 


100. EXECUTION ENVIRONMENT CONTROL 
DETERMINES WHETHER IT HAS A STUB CLASS 
APPROPRJATE FOR THE REMOTE METHOD FOR 
WHICH IT HAS A REFERENCE 


YES 


101. CONTINUE 


FIG. 2 


NO 


102. CONTROL MODULE DETERMINES WHETHER 
INVOCATION INCLUDED A RESOURCE IDENTIFIER 
OR IF A RESOURCE IDENTIFIER FOR THE CALL IS 
OTHERWISE PROVIDED 

' \ 

YES 


i 


103. CONTROL MODULE ENABLES STUB CLASS 
LOADER TO INITIATE COMMUNICATIONS WITH 
IDENTIFIED SERVER COMPUTER TO OBTAIN STUB 
CUXSS INSTANCE FOR THE CLASS AND METHOD TO 
BE INVOKED 


i 


104. WHEN STUB CLASS LOADER RECEIVES STUB 
CLASS INSTANCE, CONTROL MODULE LOADS IT 
INTO EXECUTION ENVIRONMENT 
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F I a 2 (CONT. A) 


110. CONTROL MODULE USES STUB CLASS 
LOADER IS CALLED TO. IN TURN, CALL DEFAULT 
STUB CLASS INSTANCE IS TO LOCATE 
APPROPRJATE SERVER COMPUTER, INCLUDING 
IDENTIFICATION OF CLASS AND METHOD TO BE 
INVOKED 


111, NAMESERVER COMPUTER PROCESSES 
COMMUNICATIONS FROM DEFAULT STUB CLASS 
INSTANCE AS A REMOTE METHOD INVOCATION, TO 
OBTAIN RESULT INFORMATION 


/ 

112. NAMESERVER COMPUTER INITIATES 
COMMUNICATIONS TO PROVIDE THE RESULT 
INFORMATION TO THE DEFAULT STUB CLASS 
INSTANCE 
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FIG. 2 (com. B) 


113. RESULT INFORMATION IS PROVIDED TO STUB 
CLASS LOADER 


114. STUB CLASS LOADER DETERMINES WHETHER 
RESULT INFORMATION IS A RESOURCE IDENTIFIER 
OR AN INDICATION THAT NO RESOURCE IDENTIFIER 
EXISTS FOR THE CLASS AND METHOD 


0 


RESOURCE 
IDENTIFIER 


NO RESOURCE 
IDENTIFIER 


115. EXCEPTION 
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FIG. 3 


120. EXECUTION ENVIRONMENT CONTROL VERIFIES 
THAT IT HAS STUB CLASS INSTANCE FOR REMOTE 
METHOD WHICH HAS BEEN INVOKED 

I 

YES 


121. CAU. INTERFACE PROVIDED BY STUB CLASS 
INSTANCE TO INVOKE REMOTE METHOD 
PROVIDING PARAMETER VALUES WHICH ARE TO BE 
USED IN PROCESSING THE REMOTE METHOD 


122. STUB CLASS INSTANCE FOR REMOTE METHOD 
TO BE INVOKED INITIATES COMMUNICATIONS WITH 
SERVER COMPUTER WHICH MAJNTAINS CLASS FOR 
REMOTE METHOD. IN THE PROCESS PASSING 
PARAMETER VALUES WHICH ARE TO BE USED IN 
PROCESSING THE REMOTE METHOD 


123. SERVER COMPUTER ESTABUSHES AN 
EXECUTION ENVIRONMENT FOR METHOD TO BE 
INVOKED. USES INFORMATION PROVIDED BY 
SKELETON TO CREATE A CLASS INSTANCE FOR 
THE CLASS WHICH MAINTAINS THE METHOD TO BE 
INVOKED 
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0 


F I a 3 (CONT. A) 


0 


124. SERVER COMPUTER PROCESSES THE METHOD 
IN CONNECTION WITH PARAMETER VALUES 
PROVIDED BY STUB CLASS INSTANCE 


125. SERVER COMPUTER INITIATES 
COMMUNICATIONS WITH THE STUB CLASS 
INSTANCE TO PROVIDE RESULT INFORMATION TO 
THE STUB CLASS INSTANCE 


126. STUB CLASS INSTANCE RECEIVES RESULT 
AND PROVIDES RESULT INFORMATION TO CALLING 
CLASS INSTANCE 


127. EXCEPTION 


3NSD0C!D:<tP 0603811 A2> 


17 


THIS PAGE BLANK (usPTO) 


